The W3C (WorldWide Web Consortium) defines a Web service as a software system designed to support interoperable machine-to-machine interaction over a network. It fulfills a specific set of tasks and has an interface described in a machine-processable format. A Web service is described using a standard, formal XML (eXtensible Markup Language) notation, called its service description, which provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location. The nature of the interface hides the implementation details of the service so that it can be used independently of the hardware or software platform on which it is implemented and independently of the programming language in which it is written. This allows and encourages Web services-based applications to be loosely coupled, component oriented, cross-technology implementations. Web services can be used alone or in conjunction with other Web services to carry out a complex aggregation or a business transaction.
The Web services architecture is based upon interactions between three components: a service provider, a service requester, and an optional service registry. The service provider is a system that provides a Web service. The service requester is a component which is responsible for requesting a Web service from a service provider. Both may include application programs, middleware, and a platform on which they both run.
The service registry provides a place where service providers can publish descriptions of the services they provide, and where service requesters can go to find them. The registry is an optional component of the Web services architecture, as there are many situations where service requesters and providers can communicate without it. For example, the organization that provides a service can distribute the service description directly to the users of the service, using an attachment in an e-mail, or a download from an FTP (File Transfer Protocol) site, or even a CD-ROM distribution.
A message is the basic unit of data sent from one Web services agent to another in the context of Web services. The structure of a message is defined in the service description. The main parts of a message are its envelope, a set of zero or more headers, and the message body. The envelope serves to encapsulate the component parts of the message and it serves as a well-known location for message transport services to locate necessary addressing information. The message body contains the application-specific content intended for the message recipient. The header holds ancillary information about the message and facilitates modular processing. Message headers may have separate semantics from the message body; for example, there may be standard forms of message header that describe authentication of messages.
Many Web services use a protocol called SOAP, (formerly known as the Simple Object Access Protocol), for the exchange of information. SOAP messages are encoded as XML documents and can be exchanged using a variety of underlying transport protocols.
In standard SOAP messages, binary objects must be base64 encoded and included in the message body, which significantly increases the size of the objects (by 33%), as 6 bits of the binary object become 8 bits for transmission. For very large binary objects, this size increase can significantly impact network performance and transmission time.
A known mechanism which can be used to overcome this problem separates out the binary data and sends it in a separate binary attachment. This mechanism uses the SOAP Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP) specifications (often referred to as MTOM/XOP) developed by the World Wide Web Consortium; (see http://www.w3.org/TR/soap12-mtom/ and http://www.w3.org/TR/xop10/ for more details).
When MTOM/XOP is used to optimize a SOAP message, it is serialized it into a MIME (Multipurpose Internet Mail Extensions) Multipart/Related message. XOP processing converts the XML in the SOAP message to XOP format by replacing the base64Binary data with a special <xop:Include> element to reference each relevant MIME attachment using a URI. The modified SOAP message is called the XOP document and it forms the root document within the message. The XOP document and binary attachments together form the XOP package. When applied to the SOAP MTOM specification, the XOP package is a MIME message in MTOM format.
FIG. 1 shows the transformation of a SOAP message 10, containing a header 11 and body 12, containing a base64Binary encoded data object 13, into a MIME Multipart/Related XOP package 14. The XOP package 14 contains a MIME header 15, a first body part 16, the root, containing an XML representation of the modified SOAP envelope, and an additional message part, binary attachment 17, which is referenced by the root and used to contain the binary representation of each element that has been optimized, as shown in FIG. 1.
So, using MTOM/XOP optimization can avoid the inclusion of large base64Binary data objects in the SOAP message. However, if expected binary objects are not present in a received SOAP message, then certain Web Service provider functions will fail as they require the original SOAP message body and/or headers. Such functions include runtime message validation as well as WS-Security operations, which require a copy of the original message.
One possible solution is to automatically reconstruct all MTOM messages on receipt before passing them onto a message handler or pipeline of message handlers for the requested Web Service. (A message handler is a program which performs processing of Web service requests and responses. A pipeline is a set of message handlers that are executed in sequence.) However, this means that the message handlers must deal with the larger sized SOAP messages and the speed of processing (e.g. XML parsing) of the data by the message handler(s) or pipeline may be significantly reduced.
The present invention aims to address this problem.